Ssl proxy whitelisting

ABSTRACT

A network device may receive a first data packet. The network device may determine that a level of available computing resources satisfies a threshold level. The network device may perform a secure socket layer (SSL) proxy function based on the level of available computing resources satisfying the threshold level. The network device may receive a second data packet. The network device may determine that the level of available computing resources fails to satisfy the threshold level. The network device may determine a security characteristic associated with the second data packet. The network device may determine a security rating associated with the second data packet based on the security characteristic. The network device may selectively perform the SSL proxy function based on the security rating.

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to Indian Nonprovisional PatentApplication No. 202041015922 entitled “SSL PROXY WHITELISTING,” filed onApr. 13, 2020. The entire content of which is expressly incorporatedherein by reference.

BACKGROUND

Secure sockets layer (SSL) is an application-level protocol thatprovides encryption technology for data transmitted between a client anda server. SSL utilizes certificates and private-public key exchangepairs to enable the secure transmission of data between a client and aserver. SSL proxy is a transparent proxy that performs SSL encryptionand decryption for the data transmitted between the client and theserver.

SUMMARY

According to some implementations, a method may include receiving, by anetwork device, a first data packet; determining, by the network device,that a level of available computing resources satisfies a thresholdlevel; performing, by the network device, a secure socket layer (SSL)proxy function based on the level of available computing resourcessatisfying the threshold level; forwarding, by the network device, thefirst data packet based on performing the SSL proxy function; receiving,by the network device, a second data packet; determining, by the networkdevice, that the level of available computing resources fails to satisfythe threshold level; determining, by the network device, a securitycharacteristic associated with the second data packet based on the levelof available computing resources failing to satisfy the threshold level,wherein the security characteristic is based on: an applicationvulnerability indication associated with the second data packet, and auser identity indication associated with the second data packet;determining, by the network device, a security rating associated withthe second data packet based on the security characteristic; andselectively performing, by the network device, the SSL proxy functionbased on the security rating, wherein the network device forwards thesecond data packet without performing the SSL proxy function based onthe security rating comprising a first security rating, and wherein thenetwork device performs the SSL function when the security ratingcomprises a second security rating.

According to some implementations, a device may include one or morememories and one or more processors. The one or more processors may beconfigured to: receive a data packet; determine that a level ofavailable computing resources fails to satisfy a threshold level ofavailable computing resources; determine a security characteristicassociated with the data packet based on the level of availablecomputing resources failing to satisfy the threshold level of availablecomputing resources; determine a security rating associated with thedata packet based on the security characteristic; and selectivelyperform a secure socket layer (SSL) proxy function based on the securityrating, wherein the data packet is forwarded without performing the SSLproxy function based on the security rating comprising a first securityrating, and wherein the SSL function is performed when the securityrating comprises a second security rating.

According to some implementations, a non-transitory computer-readablemedium may store one or more instructions. The one or more instructions,when executed by one or more processors of a device, may cause the oneor more processors to: determine that a level of available computingresources satisfies a threshold level of available computing resourcesduring a first time period; perform a secure socket layer (SSL) proxyfunction for each data packet received during the first time periodbased on the level of available computing resources satisfying thethreshold level of available computing resources; determine that thelevel of available computing resources fails to satisfy the thresholdlevel of available computing resources during a second time period;selectively perform the SSL proxy function for each data packet receivedduring the second time period based on the level of available computingresources failing to satisfy the threshold level of available computingresources, wherein the SSL proxy function is not performed for a firstdata packet received during the second time period based the first datapacket being classified as a low security risk data packet; and whereinthe SSL proxy function is performed for a second data packet receivedduring the second time period based the second data packet beingclassified as a high security risk data packet.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A-1E are diagrams of one or more example implementationsdescribed herein.

FIG. 2 is a diagram of an example environment in which systems and/ormethods described herein may be implemented.

FIGS. 3A-3B are diagrams of example components of one or more devices ofFIG. 2.

FIGS. 4-6 are flowchart of example processes for performing SSL proxywhitelisting.

DETAILED DESCRIPTION

The following detailed description of example implementations refers tothe accompanying drawings. The same reference numbers in differentdrawings may identify the same or similar elements.

Secure socket layer (SSL) proxy is performed at a security device (e.g.,a firewall) to enable the security device to inspect SSL encrypted data.SSL encrypted data is received at the security device via a SSL/HTTPSsession. The SSL proxy splits the SSL/HTTPS session into two sessions. Afirst session is for data transmitted between a client device and thesecurity device and a second session is for data transmitted between thesecurity device and a server device. The SSL proxy decrypts the SSLencrypted data, performs deep packet inspection on the decrypted data,encrypts the inspected data, and forwards the SSL encrypted data to theserver device via the second session.

The security device is equipped with a fail-close mechanism that causesa new session to be dropped when the available computing resources ofthe security device are insufficient to perform SSL proxy functions.Thus, the security device may prevent authorized users from accessingthe server device during periods of high demand.

Some implementations described herein may include a security device thatperforms SSL proxy whitelisting. When resource utilization is below athreshold level, the security device may perform SSL proxy functions forevery session associated with the security device. When resourceutilization is greater than a threshold level, the security device maydetermine security characteristics associated with a data packet and/ora SSL/HTTPS session. The security device may determine a vulnerabilityrating for the SSL/HTTPS session based on the security characteristics.When the vulnerability rating is determined to be a first vulnerabilityrating (e.g., safe), the data packet may be forwarded without performingSSL proxy functions (e.g., whitelisted). When the vulnerability ratingis determined to be a second vulnerability rating, SSL proxy functionsmay be performed.

By performing SSL proxy whitelisting, the security device may conservecomputing resources during periods of high demand. In this way, aquantity of sessions that can be maintained by the security device maybe increased relative to security devices that do not perform SSL proxywhitelisting. By increasing the quantity of sessions that can bemaintained by the security device, the security device may preventauthorized users from being denied access to a server during periods ofhigh demand.

FIGS. 1A-1E are diagrams of one or more example implementations 100described herein. As shown in FIGS. 1A-1E, a security device selectivelyperforms SSL proxy whitelisting based on a resource utilization level ofthe security device.

As shown in FIG. 1A, a user (shown as User1) utilizes a client device(shown as client device 1) to cause a data packet to be transmitted to aserver device. The data packet may include secure socket layer (SSL)encrypted data and may be received via a SSL/HTTPS session. The securitydevice may selectively perform SSL proxy functions on the SSL/HTTPSsession based on a computing resource (e.g., processing resource, memoryresource, communication resource, and/or the like) utilization level.

The computing resource utilization level may indicate an amount and/orpercentage of computing resources currently being utilized by thesecurity device. For example, the computing resource utilization levelmay indicate a percentage (e.g., 30%, 60%, 90%, and/or the like) of allcomputing resources, a percentage of processor resources, a percentageof memory resources, a percentage of communication resources, and/or thelike currently utilized by the security device.

Alternatively, and/or additionally, the computing resource utilizationlevel may indicate an amount and/or percentage of available computingresources. For example, the computing resource utilization level mayindicate a percentage (e.g., 10%, 40%, 60%, and/or the like) of allcomputing resources, a percentage of processor resources, a percentageof memory resources, a percentage of communication resources, and/or thelike available to be utilized by the security device to perform SSLproxy functions on the SSL/HTTPS session.

The security device may determine the computing resource utilizationlevel based on one or more counters. For example, a CPU counter may beincremented based on a processing resource being utilized and may bedecremented based on a processing thread no longer being utilized. Thesecurity device may query the CPU counter and may determine a percentageof processor resources being utilized based on a response to the query.The security device may determine a percentage of memory resources beingutilized, a percentage of communication resources being utilized, and/orthe like, in a similar manner.

The security device may selectively perform the SSL processing on theSSL/HTTPS session when the computing resource utilization levelsatisfies a threshold level. For example, the security device mayselectively perform the SSL processing on the SSL/HTTPS session when thecomputing resource utilization level indicates that over 80% of thecomputing resources associated with the security device are beingutilized, that less than 25% of the computing resources associated withthe security device are available to perform SSL proxy functions on theSSL/HTTPS session, and/or the like.

In some implementations, the security device may selectively perform SSLprocessing based on the computing resource utilization level and one ormore other factors, such as a quantity of data packets currently beingprocessed by the security device, a quantity of SSL/HTTPS sessionsmaintained by the security device, whether a time period during whichthe data packet was received is associated with a high volume of datapackets being transmitted to and/or from the security device, an amountof computing resources being utilized to perform a function other thanSSL proxy functions (e.g., an update operation being performed during aperiod of time associated with a low volume of data packets beingtransmitted to and/or from the security device), an amount of computingresources required to perform SSL proxy functions for the SSL/HTTPSsession, and/or the like. The above-listed factors are intended to bemerely examples of types of factors that may be used. In practice, thefactors may include any one or more of the above-listed factors and/orone or more other types of factors not listed above.

As shown by reference number 102, the security device determines thatthe computing resource utilization level is below a threshold level. Asshown by reference number 104, the security device performs SSL proxyfunctions on the SSL/HTTPS session based on the computing resourceutilization level being below the threshold level.

For example, the security device may split the SSL/HTTPS session intotwo sessions. A first session is for data transmitted between the clientdevice and the security device. A second session is for data transmittedbetween the security device and the server device. The security devicedecrypts the SSL encrypted data (e.g., the data packet received from theclient device), performs deep packet inspection on the decrypted data,and encrypts the inspected data. As shown by reference number 106, thesecurity device forwards the encrypted, inspected data packet to theserver device via the second session.

As shown in FIG. 1B, another user (shown as User2) utilizes anotherclient device (shown as client device 2) to cause another data packet tobe transmitted to the server device. The other data packet may includeSSL encrypted data and may be received via a second SSL/HTTPS session.The security device may determine the computing resource utilizationlevel based on receiving the data packet. In some implementations, thesecurity device determines the computing resource utilization level in amanner similar to that described above with respect to FIG. 1A.

As shown by reference number 108, the security device determines thatthe computing resource utilization level is above a threshold level. Thesecurity device determines to selectively perform SSL proxy functions onthe second SSL/HTTPS session based on the computing resource utilizationlevel being above the threshold level. The security device may whitelistthe second SSL/HTTPS session (e.g., forward the data packet to theserver device without performing an SSL proxy function on the secondSSL/HTTPS session) based on a security rating associated with the datapacket. The security rating may be determined based on one or moresecurity characteristics associated with the data packet and/or one ormore security characteristics associated with the second SSL/HTTPSsession.

As shown by reference number 110, the security device determinessecurity characteristics associated with the data packet and/or thesecond SSL/HTTPS session. The security characteristics may include oneor more application security characteristics, one or more user securitycharacteristics, one or more client device security characteristics,and/or the like.

The application security characteristics may include one or moresecurity characteristics associated with an application associated withthe data packet such as a L7+ application vulnerability ratingassociated with the application, a server-to-client vulnerabilityassociated with the application, a client-to-server vulnerabilityassociated with the application, and/or the like. The above-listedapplication security characteristics are intended to be merely examplesof types of application security characteristics that may be used. Inpractice, the application security characteristics may include any oneor more of the above-listed application security characteristics and/orone or more other types of application security characteristics notlisted above.

The security device may determine the application securitycharacteristics based on information obtained from a device associatedwith a vendor of the security device, information obtained by a deviceassociated with a third party that performs security assessments ofwebsites, information obtained by a device associated with a third partythat provides ratings of websites, information determined by thesecurity device based on historic processing and/or reporting ofvulnerabilities, information obtained from another security device,information input by a user identifying one or more safe applications,information input by a user identifying one or more unsafe applications,and/or the like.

The user security characteristics may include one or more securitycharacteristics associated with a user associated with the data packet(e.g., User2). For example, the user security characteristics mayinclude information indicating that the user is associated with computeror cyber-based criminal activity, information indicating that the useris associated with a blacklisted user, information indicating that theuser is associated with an organization associated with illegal,unlawful, unethical, and/or the like activity, information indicatingthat the user is associated with a security-to-client vulnerability,information indicating that the user is associated with aclient-to-server vulnerability, information indicating that the user isassociated with a valid username and/or password, and/or the like. Theabove-listed user security characteristics are intended to be merelyexamples of types of user security characteristics that may be used. Inpractice, the user security characteristics may include any one or moreof the above-listed user security characteristics and/or one or moreother types of user security characteristics not listed above.

The security device may obtain the user security information based oninformation obtained from a governmental database, information obtainedfrom a device associated with a third party that provides informationregarding users associated with security vulnerabilities, successfullyauthenticating the user (e.g., the user providing a valid usernameand/or password), information input by a user identifying one or moresafe users, information input by a user identifying one or more unsafeand/or high-risk users, information included in a user profileassociated with the user, and/or the like.

The client device security characteristics may include one or moresecurity characteristics associated with a client device associated withthe data packet (e.g., client device 2). For example, the client devicesecurity characteristics may include information indicating that theclient device is associated with a valid client certificate, informationindicating that the client device is associated with a client-to-servervulnerability, information indicating that the client device isassociated with an authorized user, information indicating that theclient device is associated with an unauthorized user, a user associatedwith the client device, a physical location of the client device (e.g.,located in a public area, located in a secure area, located in an officeassociated with the user, located in a home of the user, and/or thelike), a quantity of times the user utilizes the client device totransmit data packets to the server device, and/or the like. Theabove-listed client device security characteristics are intended to bemerely examples of types of client device security characteristics thatmay be used. In practice, the client device security characteristics mayinclude any one or more of the above-listed client device securitycharacteristics and/or one or more other types of client device securitycharacteristics not listed above.

The security device may determine the client device securitycharacteristics based on a valid client certificate associated with theclient device, information input by a user indicating one or more safeclient devices, information input by a user indicating one or moreunsafe client devices, client device information determined by thesecurity device based on historical security information associated withdata packets transmitted by the client device, client device securitycharacteristics obtained from another security device, and/or the like.

The security device may analyze the application security characteristicsand may determine an application security rating associated with theapplication based on the application security characteristics (e.g.,safe, low vulnerability, moderately safe, vulnerable, highvulnerability, evasive, and/or the like). The security device mayanalyze the user security characteristics and may determine a usersecurity rating associated with the user based on the user securitycharacteristics (e.g., safe, authorized, unsafe, unauthorized, low risk,medium risk, high risk, and/or the like). The security device mayanalyze the client device security characteristics and may determine aclient device security rating (e.g., safe, unsafe, validated,unvalidated, low risk, medium risk, high risk, and/or the like).

In some implementations, the security device may determine a securityrating associated with the second SSL/HTTPS session based on theapplication security rating, the user security rating, and/or the clientdevice security rating. For example, the security device may determine asecurity rating of safe for the second SSL/HTTPS session when theapplication security rating, the user security rating, and/or the clientdevice security rating satisfy a first threshold rating (e.g., safe, lowrisk, authorized, and/or the like). The security device may determine asecurity rating of unsafe for the second SSL/HTTPS session when one ormore of the application security rating, the user security rating,and/or the client device security rating fail to satisfy the thresholdrating and/or satisfy a second threshold rating (e.g., high risk,vulnerable, unsafe, and/or the like).

In some implementations, the security device uses a machine learningmodel, such as a security rating model, to determine the security ratingfor the second SSL/HTTPS session. For example, the security device maytrain the security rating model based on one or more securitycharacteristics, such as one or more application securitycharacteristics, one or more user security characteristics, one or moreclient device security characteristics, and/or the like. The securitydevice may train the security rating model using historical dataassociated with applications, users, and/or client devices according tothe one or more security characteristics. Using the historical data andthe one or more security characteristics as inputs to the securityrating model, the security device may determine a security ratingassociated with the second SSL/HTTPS session.

As shown in FIG. 1C, the security device determines the applicationsecurity rating as safe, the client device security rating as safe, andthe user security rating as safe based on the security characteristics.For example, the security device may determine the application securityrating as vulnerable safe based on a L7+ application rating and/or ahealth report associated with the application indicating that anapplication associated with the data packet is safe. The security devicemay determine the user security rating as safe based on determining thatthe user is included in a list of “safe” users stored in a memory of thesecurity device. The security device may determine the client devicesecurity rating as safe based on determining that the client device isphysically located in a secure area.

The security device may determine that the application security rating,the client device security rating, and the user security rating satisfythe first threshold rating. As shown by reference number 112, thesecurity device determines a security rating of safe for the secondSSL/HTTPS session based on the application security rating, the clientdevice security rating, and the user security rating satisfy the firstthreshold rating.

As shown by reference number 114, the security device whitelists thesecond SSL/HTTPS session based on determining the security rating ofsafe for the second SSL/HTTPS session. For example, the security devicemay add information relating to the data packet, such as the sourceaddress, the destination address, an identifier associated with thesecond SSL/HTTPS session, information identifying the security rating,information identifying the application, information identifying theuser, information identifying the client device, and/or the like to atable that stores information identifying data packets for whichperformance of SSL proxy functions can be bypassed.

The security device forwards the data packet to the server devicewithout performing SSL proxy functions on the second SSL/HTTPS sessionbased on whitelisting the second SSL/HTTPS session. By whitelisting thesecond SSL/HTTPS session, the security device may conserve computingresources by forwarding data packets received via SSL/HTTPS sessionsdetermined to be safe, low risk, and/or the like without performing SSLproxy functions. In this way, a quantity of sessions that can bemaintained by the security device may be increased relative to asecurity device that performs SSL proxy functions on every SSL/HTTPSsession (e.g., with no whitelisting). By increasing the quantity ofsessions that can be maintained by the security device, the securitydevice may prevent authorized users from being denied access to a serverduring periods of high demand.

As shown in FIG. 1D, another user (shown as User3) utilizes anotherclient device (shown as client device 3) to cause another data packet tobe transmitted to the server device. The other data packet may includeSSL encrypted data and may be received via a third SSL/HTTPS session.The security device may determine the computing resource utilizationlevel based on receiving the data packet. In some implementations, thesecurity device determines the computing resource utilization level in amanner similar to that described above with respect to FIG. 1A.

As shown by reference number 116, the security device determines thatthe computing resource utilization level is above a threshold level. Thesecurity device determines to selectively perform SSL proxy functions onthe third SSL/HTTPS session based on the computing resource utilizationlevel being above the threshold level. The security device may whitelistthe third SSL/HTTPS session based on a security rating associated withthe data packet. The security rating may be determined based on one ormore security characteristics associated with the data packet and/or thethird SSL/HTTPS session.

As shown by reference number 118, the security device determinessecurity characteristics associated with the data packet and/or thethird SSL/HTTPS session. In some implementations, the security devicemay determine the security characteristics in a manner similar to thatdescribed above with respect to FIG. 1B.

The security device may determine a security rating for the thirdSSL/HTTPS session based on the security characteristics. In someimplementations, the security device determines the security rating forthe third SSL/HTTPS session in a manner similar to that described abovewith respect to FIG. 1B.

As shown in FIG. 1E, the security device determines the applicationsecurity rating as vulnerable, the user security rating as high risk,and the client device security rating as unvalidated. For example, thesecurity device may determine the application security rating asvulnerable based on a L7+ application rating and/or a health reportassociated with the application indicating that an applicationassociated with the data packet is vulnerable with respect to one ormore known security issues. The security device may determine the usersecurity rating as high risk based on determining that the user is notincluded in a list of “safe” users stored in a memory of the securitydevice, information obtained from a governmental database indicatingthat the user is associated with a security breach, and/or the like. Thesecurity device may determine the client device security rating asunvalidated based on a client certificate associated with the clientdevice being expired.

As shown by reference number 120, the security device determines asecurity rating of unsafe for the third SSL/HTTPS session based on theapplication security rating, the user security rating, and/or the clientdevice security rating failing to satisfy the first threshold and/orsatisfying the second threshold.

As shown by reference number 122, the security device performs SSL proxyfunctions on the third SSL/HTTPS session based on the security ratingbeing determined as unsafe. In some implementations, the security devicedetermines not to forward the data packet to the server device based onperforming SSL proxy functions. For example, the security device maydecrypt the encrypted data packet and a perform deep packet inspectionprocess on the decrypted data packet. The security device may detect asecurity issue associated with the data packet based on performing thedeep packet inspection process (e.g., that the data packet containsmalicious code). The security device may perform one or more actionsbased on determining the security issue. For example, the securitydevice may blacklist the third SSL/HTTPS session (e.g., storeinformation associated with the data packet, the third SSL/HTTPSsession, the security issue, the user, the application, the clientdevice, and/or the like in a data structure (e.g., a database stored ina memory associated with the security device) indicating that SSL proxyfunctions are to be performed on data packets associated with the thirdSSL/HTTPS session, data packets associated with the user, data packetsassociated with the application, data packets associated with the clientdevice, and/or the like), may prevent the data packet from beingforwarded to the server device, may drop the data packet, may provideinformation associated with the data packet, the security issue, theuser, the application, the client device, and/or the like to anothersecurity device, and/or the like.

In other implementations, as shown in FIG. 1E, and by reference number124, the security device forwards the data packet to the server devicebased on performing SSL proxy functions on the third SSL/HTTPS session.

As indicated above, FIGS. 1A-1E are provided merely as one or moreexamples. Other examples may differ from what is described with regardto FIGS. 1A-1E.

FIG. 2 is a diagram of an example environment 200 in which systemsand/or methods described herein may be implemented. As shown in FIG. 2,environment 200 may include a client device 210, a security device 220,a server device 230, and a network 240. Devices of environment 200 mayinterconnect via wired connections, wireless connections, or acombination of wired and wireless connections.

Client device 210 includes one or more devices capable of receivingand/or providing information over a network (e.g., network 240) asdescribed herein. For example, client device 210 may include a computingdevice, such as a laptop computer, a tablet computer, a handheldcomputer, a desktop computer, a mobile phone (e.g., a smart phone, aradiotelephone, etc.), a personal digital assistant, or a similardevice. Client device 210 may receive information from and/or provideinformation to server device 230 (e.g., via network 240 and/or securitydevice 220). In some implementations, client device 210 may include abrowser used to interact with server device 230, such as by sendingrequests (e.g., HTTP requests) to server device 230 and/or receivingresponses (e.g., HTTP responses) from server device 230. In someimplementations, requests from client device 210 may be processed bysecurity device 220 before being sent to server device 230 as describedherein.

Security device 220 may include one or more devices capable ofprocessing and/or transferring traffic between client device 210 andserver device 230. For example, security device 220 may include anetwork device, such as a reverse proxy, a server (e.g., a proxyserver), a traffic transfer device, a gateway, a firewall, a router, abridge, a hub, a switch, a load balancer, or the like. Security device220 may selectively perform SSL proxy functions on SSL/HTTPS sessionsbased on a computing resource utilization level, as described herein. Insome implementations, security device 220 may be a physical deviceimplemented within a housing, such as a chassis. In someimplementations, security device 220 may be a virtual device implementedby one or more computer devices of a cloud computing environment or adata center.

Security device 220 may be used in connection with a single serverdevice 230 or a group of server devices 230 (e.g., a data center).Communications may be routed through security device 220 to reach theone or more server devices 230. For example, security device 220 may bepositioned within a network as a gateway to a private network thatincludes one or more server devices 230. Additionally, or alternatively,communications from client device 210 may be encoded such that thecommunications are routed to security device 220 before being routed toserver device 230.

Server device 230 may include one or more devices capable of receivingand/or providing information over a network (e.g., network 240), and/orcapable of generating, storing, and/or processing information receivedand/or provided over the network. For example, server device 230 mayinclude a computing device, such as a server (e.g., an applicationserver, a content server, a host server, a web server, etc.) or asimilar device. Server device 230 may receive information from and/orprovide information to client device 210 (e.g., via network 240 and/orsecurity device 220). Server device 230 may respond to requests (e.g.,requests for resources) received from client device 210. In someimplementations, responses from server device 230 may be processed bysecurity device 220 before being sent to client device 210.

Network 240 may include one or more wired and/or wireless networks. Forexample, network 240 may include a packet switched network, a cellularnetwork (e.g., a fifth generation (5G) network, a fourth generation (4G)network, such as a long-term evolution (LTE) network, a third generation(3G) network, a code division multiple access (CDMA) network, a publicland mobile network (PLMN), a local area network (LAN), a wide areanetwork (WAN), a metropolitan area network (MAN), a telephone network(e. g., the Public Switched Telephone Network (PSTN)), a privatenetwork, an ad hoc network, an intranet, the Internet, a fiberoptic-based network, a cloud computing network, or the like, and/or acombination of these or other types of networks.

The number and arrangement of devices and networks shown in FIG. 2 areprovided as one or more examples. In practice, there may be additionaldevices and/or networks, fewer devices and/or networks, differentdevices and/or networks, or differently arranged devices and/or networksthan those shown in FIG. 2. Furthermore, two or more devices shown inFIG. 2 may be implemented within a single device, or a single deviceshown in FIG. 2 may be implemented as multiple, distributed devices.Additionally, or alternatively, a set of devices (e.g., one or moredevices) of environment 200 may perform one or more functions describedas being performed by another set of devices of environment 200.

FIG. 3A is a diagram of example components of a device 300. Device 300may correspond to client device 210, security device 220, and/or serverdevice 230. In some implementations, client device 210, security device220, and/or server device 230 may include one or more devices 300 and/orone or more components of device 300. As shown in FIG. 3A, device 300may include a bus 305, a processor 310, a memory 315, a storagecomponent 320, an input component 325, an output component 330, and acommunication interface 335.

Bus 305 includes a component that permits communication among thecomponents of device 300. Processor 310 is implemented in hardware,firmware, or a combination of hardware and software. Processor 310 takesthe form of a central processing unit (CPU), a graphics processing unit(GPU), an accelerated processing unit (APU), a microprocessor, amicrocontroller, a digital signal processor (DSP), a field-programmablegate array (FPGA), an application-specific integrated circuit (ASIC), oranother type of processing component. In some implementations, processor310 includes one or more processors capable of being programmed toperform a function. Memory 315 includes a random access memory (RAM), aread only memory (ROM), and/or another type of dynamic or static storagedevice (e.g., a flash memory, a magnetic memory, and/or an opticalmemory) that stores information and/or instructions for use by processor310.

Storage component 320 stores information and/or software related to theoperation and use of device 300. For example, storage component 320 mayinclude a hard disk (e.g., a magnetic disk, an optical disk, amagneto-optic disk, and/or a solid state disk), a compact disc (CD), adigital versatile disc (DVD), a floppy disk, a cartridge, a magnetictape, and/or another type of non-transitory computer-readable medium,along with a corresponding drive.

Input component 325 includes a component that permits device 300 toreceive information, such as via user input (e.g., a touch screendisplay, a keyboard, a keypad, a mouse, a button, a switch, and/or amicrophone). Additionally, or alternatively, input component 325 mayinclude a sensor for sensing information (e.g., a global positioningsystem (GPS) component, an accelerometer, a gyroscope, and/or anactuator). Output component 330 includes a component that providesoutput information from device 300 (e.g., a display, a speaker, and/orone or more light-emitting diodes (LEDs)).

Communication interface 335 includes a transceiver-like component (e.g.,a transceiver and/or a separate receiver and transmitter) that enablesdevice 300 to communicate with other devices, such as via a wiredconnection, a wireless connection, or a combination of wired andwireless connections. Communication interface 335 may permit device 300to receive information from another device and/or provide information toanother device. For example, communication interface 335 may include anEthernet interface, an optical interface, a coaxial interface, aninfrared interface, a radio frequency (RF) interface, a universal serialbus (USB) interface, a Wi-Fi interface, a cellular network interface, orthe like.

Device 300 may perform one or more processes described herein. Device300 may perform these processes based on processor 310 executingsoftware instructions stored by a non-transitory computer-readablemedium, such as memory 315 and/or storage component 320. Acomputer-readable medium is defined herein as a non-transitory memorydevice. A memory device includes memory space within a single physicalstorage device or memory space spread across multiple physical storagedevices.

Software instructions may be read into memory 315 and/or storagecomponent 320 from another computer-readable medium or from anotherdevice via communication interface 335. When executed, softwareinstructions stored in memory 315 and/or storage component 320 may causeprocessor 310 to perform one or more processes described herein.Additionally, or alternatively, hardwired circuitry may be used in placeof or in combination with software instructions to perform one or moreprocesses described herein. Thus, implementations described herein arenot limited to any specific combination of hardware circuitry andsoftware.

The quantity and arrangement of components shown in FIG. 3A are providedas an example. In practice, device 300 may include additionalcomponents, fewer components, different components, or differentlyarranged components than those shown in FIG. 3A. Additionally, oralternatively, a set of components (e.g., one or more components) ofdevice 300 may perform one or more functions described as beingperformed by another set of components of device 300.

FIG. 3B is a diagram of example components of a device 350. Device 350may correspond to one or more of client device 210, security device 220,and/or server device 230. In some implementations, one or more clientdevice 210, security device 220, and/or server device 230 may includeone or more devices 350 and/or one or more components of device 350. Asshown in FIG. 3B, device 350 may include one or more input components355-1 through 355-B (B≥1) (hereinafter referred to collectively as inputcomponents 355, and individually as input component 355), a switchingcomponent 360, one or more output components 365-1 through 365-C (C≥1)(hereinafter referred to collectively as output components 365, andindividually as output component 365), and a controller 370.

Input components 355 may be points of attachment for physical links andmay be points of entry for incoming traffic, such as packets. Inputcomponents 355 may process incoming traffic, such as by performing datalink layer encapsulation or decapsulation. In some implementations,input components 355 may send and/or receive packets. In someimplementations, input components 355 may include an input line cardthat includes one or more packet processing components (e.g., in theform of integrated circuits), such as one or more interface cards(IFCs), packet forwarding components, line card controller components,input ports, processors, memories, and/or input queues. In someimplementations, device 350 may include one or more input components355.

Switching component 360 may interconnect input components 355 withoutput components 365. In some implementations, switching component 360may be implemented via one or more crossbars, via busses, and/or withshared memories. The shared memories may act as temporary buffers tostore packets from input components 355 before the packets areeventually scheduled for delivery to output components 365. In someimplementations, switching component 360 may enable input components355, output components 365, and/or controller 370 to communicate.

Output component 365 may store packets and may schedule packets fortransmission on output physical links. Output component 365 may supportdata link layer encapsulation or decapsulation, and/or a variety ofhigher-level protocols. In some implementations, output component 365may send packets and/or receive packets. In some implementations, outputcomponent 365 may include an output line card that includes one or morepacket processing components (e.g., in the form of integrated circuits),such as one or more IFCs, packet forwarding components, line cardcontroller components, output ports, processors, memories, and/or outputqueues. In some implementations, device 350 may include one or moreoutput components 365. In some implementations, input component 355 andoutput component 365 may be implemented by the same set of components(e.g., and input/output component may be a combination of inputcomponent 355 and output component 365).

Controller 370 includes a processor in the form of, for example, a CPU,a GPU, an APU, a microprocessor, a microcontroller, a DSP, an FPGA, anASIC, and/or another type of processor. The processor is implemented inhardware, firmware, or a combination of hardware and software. In someimplementations, controller 370 may include one or more processors thatcan be programmed to perform a function.

In some implementations, controller 370 may include a RAM, a ROM, and/oranother type of dynamic or static storage device (e.g., a flash memory,a magnetic memory, an optical memory, etc.) that stores informationand/or instructions for use by controller 370.

In some implementations, controller 370 may communicate with otherdevices, networks, and/or systems connected to device 300 to exchangeinformation regarding network topology. Controller 370 may createrouting tables based on the network topology information, createforwarding tables based on the routing tables, and forward theforwarding tables to input components 355 and/or output components 365.Input components 355 and/or output components 365 may use the forwardingtables to perform route lookups for incoming and/or outgoing packets.

Controller 370 may perform one or more processes described herein.Controller 370 may perform these processes in response to executingsoftware instructions stored by a non-transitory computer-readablemedium. A computer-readable medium is defined herein as a non-transitorymemory device. A memory device includes memory space within a singlephysical storage device or memory space spread across multiple physicalstorage devices.

Software instructions may be read into a memory and/or storage componentassociated with controller 370 from another computer-readable medium orfrom another device via a communication interface. When executed,software instructions stored in a memory and/or storage componentassociated with controller 370 may cause controller 370 to perform oneor more processes described herein. Additionally, or alternatively,hardwired circuitry may be used in place of or in combination withsoftware instructions to perform one or more processes described herein.Thus, implementations described herein are not limited to any specificcombination of hardware circuitry and software.

The quantity and arrangement of components shown in FIG. 3B are providedas an example. In practice, device 350 may include additionalcomponents, fewer components, different components, or differentlyarranged components than those shown in FIG. 3B. Additionally, oralternatively, a set of components (e.g., one or more components) ofdevice 350 may perform one or more functions described as beingperformed by another set of components of device 350.

FIG. 4 is a flow chart of an example process 400 for performing SSLproxy whitelisting. In some implementations, one or more process blocksof FIG. 4 may be performed by a network device (e.g., security device220). In some implementations, one or more process blocks of FIG. 4 maybe performed by another device or a group of devices separate from orincluding the network device, such as a client device (e.g., clientdevice 210), a server device (e.g., server device 230), and/or the like.

As shown in FIG. 4, process 400 may include receiving a first datapacket (block 410). For example, the network device (e.g., usingprocessor 310, memory 315, storage component 320, input component 325,output component 330, communication interface 335, input component 355,switching component 360, output component 365, controller 370, and/orthe like) may receive a first data packet, as described above.

As further shown in FIG. 4, process 400 may include determining that alevel of available computing resources satisfies a threshold level(block 420). For example, the network device (e.g., using processor 310,memory 315, storage component 320, input component 325, output component330, communication interface 335, input component 355, switchingcomponent 360, output component 365, controller 370, and/or the like)may determine that a level of available computing resources satisfies athreshold level, as described above.

As further shown in FIG. 4, process 400 may include performing a securesocket layer (SSL) proxy function based on the level of availablecomputing resources satisfying the threshold level (block 430). Forexample, the network device (e.g., using processor 310, memory 315,storage component 320, input component 325, output component 330,communication interface 335, input component 355, switching component360, output component 365, controller 370, and/or the like) may performa secure socket layer (SSL) proxy function based on the level ofavailable computing resources satisfying the threshold level, asdescribed above.

As further shown in FIG. 4, process 400 may include forwarding the firstdata packet based on performing the SSL proxy function (block 440). Forexample, the network device (e.g., using processor 310, memory 315,storage component 320, input component 325, output component 330,communication interface 335, input component 355, switching component360, output component 365, controller 370, and/or the like) may forwardthe first data packet based on performing the SSL proxy function, asdescribed above.

As further shown in FIG. 4, process 400 may include receiving a seconddata packet (block 450). For example, the network device (e.g., usingprocessor 310, memory 315, storage component 320, input component 325,output component 330, communication interface 335, input component 355,switching component 360, output component 365, controller 370, and/orthe like) may receive a second data packet, as described above.

As further shown in FIG. 4, process 400 may include determining that thelevel of available computing resources fails to satisfy the thresholdlevel (block 460). For example, the network device (e.g., usingprocessor 310, memory 315, storage component 320, input component 325,output component 330, communication interface 335, input component 355,switching component 360, output component 365, controller 370, and/orthe like) may determine that the level of available computing resourcesfails to satisfy the threshold level, as described above.

As further shown in FIG. 4, process 400 may include determining asecurity characteristic associated with the second data packet based onthe level of available computing resources failing to satisfy thethreshold level, wherein the security characteristic is based on: anapplication vulnerability indication associated with the second datapacket, and a user identity indication associated with the second datapacket (block 470). For example, the network device (e.g., usingprocessor 310, memory 315, storage component 320, input component 325,output component 330, communication interface 335, input component 355,switching component 360, output component 365, controller 370, and/orthe like) may determine a security characteristic associated with thesecond data packet based on the level of available computing resourcesfailing to satisfy the threshold level, as described above. In someimplementations, the security characteristic is based on an applicationvulnerability indication associated with the second data packet. In someimplementations, the security characteristic is based on a user identityindication associated with the second data packet.

As further shown in FIG. 4, process 400 may include determining asecurity rating associated with the second data packet based on thesecurity characteristic (block 480). For example, the network device(e.g., using processor 310, memory 315, storage component 320, inputcomponent 325, output component 330, communication interface 335, inputcomponent 355, switching component 360, output component 365, controller370, and/or the like) may determine a security rating associated withthe second data packet based on the security characteristic, asdescribed above.

As further shown in FIG. 4, process 400 may include selectivelyperforming the SSL proxy function based on the security rating, whereinthe network device forwards the second data packet without performingthe SSL proxy function based on the security rating comprising a firstsecurity rating, and wherein the network device performs the SSLfunction when the security rating comprises a second security rating(block 490). For example, the network device (e.g., using processor 310,memory 315, storage component 320, input component 325, output component330, communication interface 335, input component 355, switchingcomponent 360, output component 365, controller 370, and/or the like)may selectively perform the SSL proxy function based on the securityrating, as described above. In some implementations, the network deviceforwards the second data packet without performing the SSL proxyfunction based on the security rating comprising a first securityrating. In some implementations, the network device performs the SSLfunction when the security rating comprises a second security rating.

Process 400 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or in connection with one or more other processes describedelsewhere herein.

In a first implementation, the security characteristic is further basedon a security characteristic that is associated with a client devicethat is associated with the second data packet.

In a second implementation, alone or in combination with the firstimplementation, determining the security characteristic comprises:determining a vulnerability level associated with a user associated withthe second data packet based on the user identity indication.

In a third implementation, alone or in combination with one or more ofthe first and second implementations, determining that the level ofavailable computing resources fails to satisfy the threshold levelcomprises: determining that an amount of available memory associatedwith the network device fails to satisfy a threshold amount of availablememory.

In a fourth implementation, alone or in combination with one or more ofthe first through third implementations, the security rating comprisesthe second security rating, the method further comprising: identifying avulnerability associated with the second data packet based on performingthe SSL proxy function; dropping the second data packet based onidentifying the vulnerability, and storing information identifying thevulnerability in a memory associated with the network device.

In a fifth implementation, alone or in combination with one or more ofthe first through fourth implementations, process 400 includes obtaininga health rating associated with the application from a server device;and determining the application vulnerability indication based on thehealth rating.

In a sixth implementation, alone or in combination with one or more ofthe first through fifth implementations, process 400 includesdetermining the user identity indication based on one or more of:validating a client certificate associated with the second data packet;or authenticating a user associated with the second data packet.

Although FIG. 4 shows example blocks of process 400, in someimplementations, process 400 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 4. Additionally, or alternatively, two or more of theblocks of process 400 may be performed in parallel.

FIG. 5 is a flow chart of an example process 500 for performing SSLproxy whitelisting. In some implementations, one or more process blocksof FIG. 5 may be performed by a network device (e.g., security device220). In some implementations, one or more process blocks of FIG. 5 maybe performed by another device or a group of devices separate from orincluding the network device, such as a client device (e.g., clientdevice 210), a server device (e.g., server device 230), and/or the like.

As shown in FIG. 5, process 500 may include receiving a data packet(block 510). For example, the network device (e.g., using processor 310,memory 315, storage component 320, input component 325, output component330, communication interface 335, input component 355, switchingcomponent 360, output component 365, controller 370, and/or the like)may receive a data packet, as described above.

As further shown in FIG. 5, process 500 may include determining that alevel of available computing resources fails to satisfy a thresholdlevel of available computing resources (block 520). For example, thenetwork device (e.g., using processor 310, memory 315, storage component320, input component 325, output component 330, communication interface335, input component 355, switching component 360, output component 365,controller 370, and/or the like) may determine that a level of availablecomputing resources fails to satisfy a threshold level of availablecomputing resources, as described above.

As further shown in FIG. 5, process 500 may include determining asecurity characteristic associated with the data packet based on thelevel of available computing resources failing to satisfy the thresholdlevel of available computing resources (block 530). For example, thenetwork device (e.g., using processor 310, memory 315, storage component320, input component 325, output component 330, communication interface335, input component 355, switching component 360, output component 365,controller 370, and/or the like) may determine a security characteristicassociated with the data packet based on the level of availablecomputing resources failing to satisfy the threshold level of availablecomputing resources, as described above.

As further shown in FIG. 5, process 500 may include determining asecurity rating associated with the data packet based on the securitycharacteristic (block 540). For example, the network device (e.g., usingprocessor 310, memory 315, storage component 320, input component 325,output component 330, communication interface 335, input component 355,switching component 360, output component 365, controller 370, and/orthe like) may determine a security rating associated with the datapacket based on the security characteristic, as described above.

As further shown in FIG. 5, process 500 may include selectivelyperforming a secure socket layer (SSL) proxy function based on thesecurity rating, wherein the data packet is forwarded without performingthe SSL proxy function based on the security rating comprising a firstsecurity rating, and wherein the SSL function is performed when thesecurity rating comprises a second security rating (block 550). Forexample, the network device (e.g., using processor 310, memory 315,storage component 320, input component 325, output component 330,communication interface 335, input component 355, switching component360, output component 365, controller 370, and/or the like) mayselectively perform a secure socket layer (SSL) proxy function based onthe security rating, as described above. In some implementations, thedata packet is forwarded without performing the SSL proxy function basedon the security rating comprising a first security rating. In someimplementations, the SSL function is performed when the security ratingcomprises a second security rating.

Process 500 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or in connection with one or more other processes describedelsewhere herein.

In a first implementation, process 500 includes determining that a userassociated with the data packet has been authenticated; and determiningthat the security rating associated with the data packet comprises thefirst security rating based on the user having been authenticated.

In a second implementation, alone or in combination with the firstimplementation, process 500 includes determining that the data packet isassociated with a valid client certificate; and determining that thesecurity rating associated with the data packet comprises the firstsecurity rating based on the data packet being associated with the validclient certificate.

In a third implementation, alone or in combination with one or more ofthe first and second implementations, process 500 includes identifyingan application associated with the data packet; determining a healthrating associated with the application; and determining the securitycharacteristic based on the health rating.

In a fourth implementation, alone or in combination with one or more ofthe first through third implementations, process 500 includesdetermining a website associated with the data packet; and obtaininginformation identifying a security assessment associated with thewebsite; and determining the security characteristic based on thesecurity assessment.

In a fifth implementation, alone or in combination with one or more ofthe first through fourth implementations, process 500 includesdetermining an application associated with the data packet; determininga user associated with the data packet; and determining the securitycharacteristic based on the application and the user.

In a sixth implementation, alone or in combination with one or more ofthe first through fifth implementations, process 500 includes obtaininga username and a password associated with a user associated with thedata packet; authenticating the user based on the username and thepassword; and determining the security characteristic based onauthenticating the user.

Although FIG. 5 shows example blocks of process 500, in someimplementations, process 500 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 5. Additionally, or alternatively, two or more of theblocks of process 500 may be performed in parallel.

FIG. 6 is a flow chart of an example process 600 for performing SSLproxy whitelisting. In some implementations, one or more process blocksof FIG. 6 may be performed by a network device (e.g., security device220). In some implementations, one or more process blocks of FIG. 6 maybe performed by another device or a group of devices separate from orincluding the network device, such as a client device (e.g., clientdevice 210), a server device (e.g., server device 230), and/or the like.

As shown in FIG. 6, process 600 may include determining that a level ofavailable computing resources satisfies a threshold level of availablecomputing resources during a first time period (block 610). For example,the network device (e.g., using processor 310, memory 315, storagecomponent 320, input component 325, output component 330, communicationinterface 335, input component 355, switching component 360, outputcomponent 365, controller 370, and/or the like) may determine that alevel of available computing resources satisfies a threshold level ofavailable computing resources during a first time period, as describedabove.

As further shown in FIG. 6, process 600 may include performing a securesocket layer (SSL) proxy function for each data packet received duringthe first time period based on the level of available computingresources satisfying the threshold level of available computingresources (block 620). For example, the network device (e.g., usingprocessor 310, memory 315, storage component 320, input component 325,output component 330, communication interface 335, input component 355,switching component 360, output component 365, controller 370, and/orthe like) may perform a secure socket layer (SSL) proxy function foreach data packet received during the first time period based on thelevel of available computing resources satisfying the threshold level ofavailable computing resources, as described above.

As further shown in FIG. 6, process 600 may include determining that thelevel of available computing resources fails to satisfy the thresholdlevel of available computing resources during a second time period(block 630). For example, the network device (e.g., using processor 310,memory 315, storage component 320, input component 325, output component330, communication interface 335, input component 355, switchingcomponent 360, output component 365, controller 370, and/or the like)may determine that the level of available computing resources fails tosatisfy the threshold level of available computing resources during asecond time period, as described above.

As further shown in FIG. 6, process 600 may include selectivelyperforming the SSL proxy function for each data packet received duringthe second time period based on the level of available computingresources failing to satisfy the threshold level of available computingresources, wherein the SSL proxy function is not performed for a firstdata packet received during the second time period based the first datapacket being classified as a low security risk data packet, and whereinthe SSL proxy function is performed for a second data packet receivedduring the second time period based the second data packet beingclassified as a high security risk data packet (block 640). For example,the network device (e.g., using processor 310, memory 315, storagecomponent 320, input component 325, output component 330, communicationinterface 335, input component 355, switching component 360, outputcomponent 365, controller 370, and/or the like) may selectively performthe SSL proxy function for each data packet received during the secondtime period based on the level of available computing resources failingto satisfy the threshold level of available computing resources, asdescribed above. In some implementations, the SSL proxy function is notperformed for a first data packet received during the second time periodbased the first data packet being classified as a low security risk datapacket. In some implementations, the SSL proxy function is performed fora second data packet received during the second time period based thesecond data packet being classified as a high security risk data packet.

Process 600 may include additional implementations, such as any singleimplementation or any combination of implementations described belowand/or in connection with one or more other processes describedelsewhere herein.

In a first implementation, process 600 includes determining that thelevel of available computing resources satisfies the threshold level ofavailable computing resources during a third time period; and performingthe SSL proxy function for each data packet received during the thirdtime period based on the level of available computing resourcessatisfying the threshold level of available computing resources.

In a second implementation, alone or in combination with the firstimplementation, process 600 includes obtaining information identifying agroup of users associated with a security risk rating; determining thata user associated with the second data packet is associated with thesecurity risk rating based on the information identifying the group ofusers; and classifying the second data packet as the high security riskdata packet based on the user being associated with the security riskrating.

In a third implementation, alone or in combination with one or more ofthe first and second implementations, process 600 includes determiningan application associated with the second data packet; determining thatthe application is associated with a security vulnerability; andclassifying the second data as the high security risk data packet basedon the application being associated with the security vulnerability.

In a fourth implementation, alone or in combination with one or more ofthe first through third implementations, process 600 includesdetermining an amount of available processor resources; and determiningthat the level of available computing resources satisfies the thresholdlevel of available computing resources during the first time periodbased on the amount of available processor resources.

In a fifth implementation, alone or in combination with one or more ofthe first through fourth implementations, process 600 includesidentifying a security vulnerability associated with the second datapacket based on performing the SSL proxy function; and determining notto forward the second data packet based on identifying the securityvulnerability.

Although FIG. 6 shows example blocks of process 600, in someimplementations, process 600 may include additional blocks, fewerblocks, different blocks, or differently arranged blocks than thosedepicted in FIG. 6. Additionally, or alternatively, two or more of theblocks of process 600 may be performed in parallel.

The foregoing disclosure provides illustration and description, but isnot intended to be exhaustive or to limit the implementations to theprecise forms disclosed. Modifications and variations may be made inlight of the above disclosure or may be acquired from practice of theimplementations.

As used herein, the term “component” is intended to be broadly construedas hardware, firmware, and/or a combination of hardware and software.

Some implementations are described herein in connection with thresholds.As used herein, satisfying a threshold may, depending on the context,refer to a value being greater than the threshold, more than thethreshold, higher than the threshold, greater than or equal to thethreshold, less than the threshold, fewer than the threshold, lower thanthe threshold, less than or equal to the threshold, equal to thethreshold, or the like.

It will be apparent that systems and/or methods described herein may beimplemented in different forms of hardware, firmware, or a combinationof hardware and software. The actual specialized control hardware orsoftware code used to implement these systems and/or methods is notlimiting of the implementations. Thus, the operation and behavior of thesystems and/or methods are described herein without reference tospecific software code—it being understood that software and hardwarecan be designed to implement the systems and/or methods based on thedescription herein.

Even though particular combinations of features are recited in theclaims and/or disclosed in the specification, these combinations are notintended to limit the disclosure of various implementations. In fact,many of these features may be combined in ways not specifically recitedin the claims and/or disclosed in the specification. Although eachdependent claim listed below may directly depend on only one claim, thedisclosure of various implementations includes each dependent claim incombination with every other claim in the claim set.

No element, act, or instruction used herein should be construed ascritical or essential unless explicitly described as such. Also, as usedherein, the articles “a” and “an” are intended to include one or moreitems, and may be used interchangeably with “one or more.” Further, asused herein, the article “the” is intended to include one or more itemsreferenced in connection with the article “the” and may be usedinterchangeably with “the one or more.” Furthermore, as used herein, theterm “set” is intended to include one or more items (e.g., relateditems, unrelated items, a combination of related and unrelated items,etc.), and may be used interchangeably with “one or more.” Where onlyone item is intended, the phrase “only one” or similar language is used.Also, as used herein, the terms “has,” “have,” “having,” or the like areintended to be open-ended terms. Further, the phrase “based on” isintended to mean “based, at least in part, on” unless explicitly statedotherwise. Also, as used herein, the term “or” is intended to beinclusive when used in a series and may be used interchangeably with“and/or,” unless explicitly stated otherwise (e.g., if used incombination with “either” or “only one of”).

What is claimed is:
 1. A method, comprising: receiving, by a networkdevice, a first data packet; determining, by the network device, that alevel of available computing resources satisfies a threshold level;performing, by the network device, a secure socket layer (SSL) proxyfunction based on the level of available computing resources satisfyingthe threshold level; forwarding, by the network device, the first datapacket based on performing the SSL proxy function; receiving, by thenetwork device, a second data packet; determining, by the networkdevice, that the level of available computing resources fails to satisfythe threshold level; determining, by the network device, a securitycharacteristic associated with the second data packet based on the levelof available computing resources failing to satisfy the threshold level,wherein the security characteristic is based on: an applicationvulnerability indication associated with the second data packet, and auser identity indication associated with the second data packet;determining, by the network device, a security rating associated withthe second data packet based on the security characteristic; andselectively performing, by the network device, the SSL proxy functionbased on the security rating, wherein the network device forwards thesecond data packet without performing the SSL proxy function based onthe security rating comprising a first security rating, and wherein thenetwork device performs the SSL function when the security ratingcomprises a second security rating.
 2. The method of claim 1, whereinthe security characteristic is further based on a securitycharacteristic that is associated with a client device that isassociated with the second data packet.
 3. The method of claim 1,wherein determining the security characteristic comprises: determining avulnerability level associated with a user associated with the seconddata packet based on the user identity indication.
 4. The method ofclaim 1, wherein determining that the level of available computingresources fails to satisfy the threshold level comprises: determiningthat an amount of available memory associated with the network devicefails to satisfy a threshold amount of available memory.
 5. The methodof claim 1, wherein the security rating comprises the second securityrating, the method further comprising: identifying a vulnerabilityassociated with the second data packet based on performing the SSL proxyfunction; dropping the second data packet based on identifying thevulnerability; and storing information identifying the vulnerability ina memory associated with the network device.
 6. The method of claim 1,further comprising: obtaining a health rating associated with anapplication associated with the second data packet from a server device;and determining the application vulnerability indication based on thehealth rating.
 7. The method of claim 1, further comprising: determiningthe user identity indication based on one or more of: validating aclient certificate associated with the second data packet; orauthenticating a user associated with the second data packet.
 8. Adevice, comprising: one or more memories; and one or more processors to:receive a data packet; determine that a level of available computingresources fails to satisfy a threshold level of available computingresources; determine a security characteristic associated with the datapacket based on the level of available computing resources failing tosatisfy the threshold level of available computing resources; determinea security rating associated with the data packet based on the securitycharacteristic; and selectively perform a secure socket layer (SSL)proxy function based on the security rating, wherein the data packet isforwarded without performing the SSL proxy function based on thesecurity rating comprising a first security rating, and wherein the SSLfunction is performed when the security rating comprises a secondsecurity rating.
 9. The device of claim 8, wherein the one or moreprocessors, when determining the security characteristic, are to:determine that a user associated with the data packet has beenauthenticated; and wherein the one or more processors, when determiningthe security rating, are to: determine that the security ratingassociated with the data packet comprises the first security ratingbased on the user having been authenticated.
 10. The device of claim 8,wherein the one or more processors, when determining the securitycharacteristic, are to: determine that the data packet is associatedwith a valid client certificate; and wherein the one or more processors,when determining the security rating, are to: determine that thesecurity rating associated with the data packet comprises the firstsecurity rating based on the data packet being associated with the validclient certificate.
 11. The device of claim 8, wherein the one or moreprocessors, when determining the security characteristic, are to:identify an application associated with the data packet; determine ahealth rating associated with the application; and determine thesecurity characteristic based on the health rating.
 12. The device ofclaim 8, wherein the one or more processors, when determining thesecurity characteristic, are to: determine a website associated with thedata packet; and obtain information identifying a security assessmentassociated with the website; and determine the security characteristicbased on the security assessment.
 13. The device of claim 8, wherein theone or more processors, when determining the security characteristic,are to: determine an application associated with the data packet;determine a user associated with the data packet; and determine thesecurity characteristic based on the application and the user.
 14. Thedevice of claim 8, wherein the one or more processors, when determiningthe security characteristic, are to: obtain a username and a passwordassociated with a user associated with the data packet; authenticate theuser based on the username and the password; and determine the securitycharacteristic based on authenticating the user.
 15. A non-transitorycomputer-readable medium storing instructions, the instructionscomprising: one or more instructions that, when executed by one or moreprocessors, cause the one or more processors to: determine that a levelof available computing resources satisfies a threshold level ofavailable computing resources during a first time period; perform asecure socket layer (SSL) proxy function for each data packet receivedduring the first time period based on the level of available computingresources satisfying the threshold level of available computingresources; determine that the level of available computing resourcesfails to satisfy the threshold level of available computing resourcesduring a second time period; selectively perform the SSL proxy functionfor each data packet received during the second time period based on thelevel of available computing resources failing to satisfy the thresholdlevel of available computing resources, wherein the SSL proxy functionis not performed for a first data packet received during the second timeperiod based the first data packet being classified as a low securityrisk data packet; and wherein the SSL proxy function is performed for asecond data packet received during the second time period based thesecond data packet being classified as a high security risk data packet.16. The non-transitory computer-readable medium of claim 15, wherein theone or more instructions, when executed by the one or more processors,further cause the one or more processors to: determine that the level ofavailable computing resources satisfies the threshold level of availablecomputing resources during a third time period; and perform the SSLproxy function for each data packet received during the third timeperiod based on the level of available computing resources satisfyingthe threshold level of available computing resources.
 17. Thenon-transitory computer-readable medium of claim 15, wherein the one ormore instructions, that cause the one or more processors to selectivelyperform the SSL proxy function for each data packet received during thesecond time period, cause the one or more processors to: obtaininformation identifying a group of users associated with a security riskrating; determine that a user associated with the second data packet isassociated with the security risk rating based on the informationidentifying the group of users; and classify the second data packet asthe high security risk data packet based on the user being associatedwith the security risk rating.
 18. The non-transitory computer-readablemedium of claim 15, wherein the one or more instructions, that cause theone or more processors to selectively perform the SSL proxy function foreach data packet received during the second time period, cause the oneor more processors to: determine an application associated with thesecond data packet; determine that the application is associated with asecurity vulnerability; and classify the second data packet as the highsecurity risk data packet based on the application being associated withthe security vulnerability.
 19. The non-transitory computer-readablemedium of claim 15, wherein the one or more instructions, that cause theone or more processors to determine that the level of availablecomputing resources satisfies the threshold level of available computingresources during the first time period, cause the one or more processorsto: determine an amount of available processor resources; and determinethat the level of available computing resources satisfies the thresholdlevel of available computing resources during the first time periodbased on the amount of available processor resources.
 20. Thenon-transitory computer-readable medium of claim 15, wherein the one ormore instructions, when executed by the one or more processors, furthercause the one or more processors to: identify a security vulnerabilityassociated with the second data packet based on performing the SSL proxyfunction; and determine not to forward the second data packet based onidentifying the security vulnerability.